IBIS Macromodel Task Group

Meeting date: 14 October 2014

Members (asterisk for those attending):
Altera:                     * David Banas
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Avago (LSI)                   Xingdong Dai
Cadence Design Systems:       Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
Ericsson:                     Anders Ekholm
Intel:                        Michael Mirmak
Keysight Technologies:        Fangyi Rao
                            * Radek Biernacki
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:            * John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
QLogic Corp.                  James Zhou
                              Andy Joy
eASIC                         Marc Kowalski
SiSoft:                     * Walter Katz
                            * Todd Westerhoff
                            * Mike LaBonte
Synopsys                      Rita Horner
Teraspeed Consulting Group:   Scott McMorrow
                              Bob Ross

(Note: Agilent has changed to Keysight)

The meeting was led by Arpad Muranyi.

------------------------------------------------------------------------
Opens:

- Arpad: We have some usual attendees traveling today.

--------------------------
Call for patent disclosure:

- None

-------------
Review of ARs:

- Todd produce slides for co-optimization requirements discussion next week.
  - No report.

- Arpad to review IBIS spec for min max issues.
  - In progress.


-------------
New Discussion:

BIRD 147.1:

- Arpad: There where emails about this.
  - We may have reached a conclusion satisfying the question from SiSoft.
- Todd: Walter and I have not reached that conclusion.
- Todd summarized the question and exchange.
- Todd: Two weeks ago Ambrish was back-pedaling a bit.
  - Last week Ken said "yes" to the idea that my example file would be approvable.
- Arpad: It seemed from the emails that both answers were "yes".
- Todd: Ken's response started off sounding like a "no".
  - Ambrish jumped in to clarify that it means "yes".
  - Cadence may be reluctance.
  - A more concise confirmation would help.

- Radek: Do we need IBIS approval for private BCI files at all?
- Todd: SiSoft has in the past been beaten for proposing things that seem proprietary.
  - We are sensitive to that and want assurance the files will be accepted.
- Arpad: Do BCI files need tool vendor support?
  - If it's only a model maker issue compliance does not seem so important.
- Walter: Protocols need to be tool-agnostic.
  - They are only between the TX writer and RX writer.
  - A standard "configurator" is important.
  - TXs tend to easily handle any protocol, with the right settings.
  - BIRD 147 was written when no RX was training and other vendor's TX.
  - We've learned more about link training since then.
  - Other features have been added as afterthoughts, and are not well thought out.
  - We are working with IC vendors to find a better solution.
- Arpad: If we vote down BIRD 147 we have no other solution.
- Walter: We should have more to say next week.
- Todd: Walter has done much work and we are deciding whether to bring another BIRD forward.
- Walter: We do need closure on this.

- Arpad: Do we have progress on the co-optimization requirements slides AR?
- Todd: No.

- Arpad: Without an alternate we probably would vote yes for BIRD 147
  - That might change if there is an alternate.
- Radek: The issue of compatibility with existing TXs should be resolved.
  - We don't want 1000 BCI files either.
  - We should not vote until important questions are answered.
- Walter: I am struggling with training stimulus patterns.
  - The standards are hard to read.
  - It might not work across vendors.
  - A Tektronix webinar calls for 3 obfuscation stages to create "rich" patterns.
  - BIRD 147 doesn't suggest that possibility.
  - We need IC vendors who are now writing software models to weight in.
  - I hope to have something shortly.


BIRD 128:

- Radek: Walter submitted this?
- Walter: Ambrish and I did.
  - There has to be a well defined way to communicate to the TX in time domain.
  - I could add it to another BIRD and it would be less confusing.
- Arpad: BIRD 128 was supposed to be independent.

- Walter motioned to table BIRD 147.
- Radek seconded.
- There were no objections.

- Walter motioned to table BIRD 128.
- Radek seconded.
- There were no objections.

- Walter: The AR for me to get vendor package model input should be deleted.
- Arpad deleted that.


New Redriver Flow BIRD:

- Walter: The downstream RX does not get the correct info to optimize itself.
  - Fangyi and I had an email discussion about this.
  - He needs to be part of the conversation.
  - We can't quantify how important it is.
- Radek: We're not sure if the flow needs to be fixed or if the solution is adequate.
- Walter: IC vendors agree on the flow we are using.
  - Any other flow would have to be justified.
- Arpad: That should be avoided, for portability.


Filter/Analog Driver:

- Arpad: This is an enhanced C_comp idea.
- Randy: There is some interest in getting back to this topic.
- Walter: It goes back 2 to 6 years ago.
 - Michael Mirmak proposed a ladder network model.
 - We need something more complicated than just C_comp.
- David: We have [External Model] waiting to be used.
  - Would that be better than "single use" approaches?
- Walter: SPICE is limited to PWL.
- Arpad: IBIS-ISS has sources that could construct an I-V curve.
- Walter: It needs PWL controlled sources.
  - Final Stage Subckt was an arbitrary subckt proposal.
- Arpad: [External Circuit] could be used.
  - But C_comp compensation inside buffers would be impacted.
  - If that could be solved it might work out.
- John: We looked at that and rejected it.
  - It is not allowed to hook it into buffer circuit topology.
- Walter: Arpad's point is well taken.
  - I-V curves are well defined.
  - But the V-T curves are defined without C_comp.
  - V-T curve quality matters.
- Randy: VNA measurements of DDR4 gave a good model to 3GHz with simple RC.
  - Above that it's not as good.
  - A more complex model is needed.
- Arpad: It would still use I-V curves.
  - Could it be RX only?
- Randy: If the channel is not well terminated a more complex C_comp model is needed.
- Arpad: This sounds like a need for DDR4.
- Randy: There are a number of protocols that could us it.


BIRD 157 Parameterize [Driver Schedule]

- Arpad: Different models are needed for each frequency if [Driver Schedule] is used.
  - Not sure how much they are used.
  - They are basically a two tap SerDes.
- Randy: [Driver Schedule] is not well supported across simulators.
  - There are implementation differences.
- Walter: It was useful at 3GHz, but we don't see that any more.

-------------
IBIS Interconnect SPICE Wish List:

1) Simulator directives
